+git-annex (10.20250829) UNRELEASED; urgency=medium
+
+ * drop: --fast support when dropping from a remote.
+
+ -- Joey Hess <id@joeyh.name> Fri, 29 Aug 2025 12:34:06 -0400
+
git-annex (10.20250828) upstream; urgency=medium
* p2p: Added --enable option, which can be used to enable P2P networks
{- git-annex command
-
- - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ - Copyright 2010-2025 Joey Hess <id@joeyh.name>
-
- Licensed under the GNU AGPL version 3 or higher.
-}
performLocal lu pcc key afile numcopies mincopies preverified ud
startRemote :: LiveUpdate -> PreferredContentChecked -> AssociatedFile -> ActionItem -> SeekInput -> NumCopies -> MinCopies -> Key -> DroppingUnused -> Remote -> CommandStart
-startRemote lu pcc afile ai si numcopies mincopies key ud remote =
- starting "drop" (OnlyActionOn key ai) si $ do
+startRemote lu pcc afile ai si numcopies mincopies key ud remote = do
+ fast <- Annex.getRead Annex.fast
+ if fast
+ then do
+ remotes <- Remote.keyPossibilities (Remote.IncludeIgnored True) key
+ if remote `elem` remotes
+ then go
+ else stop
+ else go
+ where
+ go = starting "drop" (OnlyActionOn key ai) si $ do
showAction $ UnquotedString $ "from " ++ Remote.name remote
performRemote lu pcc key afile numcopies mincopies remote ud
this option can specify a remote from which the files'
contents should be removed.
+* `--fast`
+
+ When dropping from a remote, avoid doing anything when the remote is not
+ believed to contain a file. Usually each file is attempted to be dropped
+ from the remote. This can be faster, but might leave some files on the
+ remote in some cases.
+
* `--auto`
Rather than trying to drop all specified files, drop only those that
The reason drop behaves this way is that it's intended to
remove content from a remote even when the local repository's location log
-is out of sync with it. Still, it's somewhat surprising and annoying that
-it can need to do so much extra work.
+is out of sync with it. In order to avoid the surprising behavior of
+`git-annex drop foo` saying it succeeded, in a case where it turns out the
+remote just recently got the file. Still, it's somewhat surprising too, and
+annoying, that it can need to do so much extra work.
Note that checking if the remote actually has the content would be about as
slow as locking files on the other remote(s) (assuming a small numcopies).
`--fast` could be made to deal with this, making it check the location log.
--[[Joey]]
+
+> [[done]]